Network Node, Wireless Device and Methods therein in a Communications Network

ABSTRACT

A network node ( 110 ), a wireless device ( 120 ) and methods therein, for enabling the wireless device ( 120 ) to obtain configuration information from a multicast control channel, e.g. SC-MCCH, which is transmitted by the network node ( 110 ). The network node ( 110 ) transmits an indication of change of the multicast control channel, wherein the indication further indicates whether the wireless device ( 120 ) is affected by the change and needs to acquire or obtain the multicast control channel or not. The network node ( 110 ) further transmits the multicast control channel as changed according to said indication. Thereby, the wireless device ( 120 ) can decide to obtain and acquire the multicast control channel only if it is affected by the change and to refrain when not affected, which will reduce the consumption of energy in the wireless device ( 120 ).

TECHNICAL FIELD

The present disclosure relates generally to a network node, a wirelessdevice and methods therein, for enabling the wireless device to obtainconfiguration information from a multicast control channel transmittedby the network node.

BACKGROUND

In a typical wireless communication network, wireless devices, alsoknown as wireless communication devices, mobile stations, stations (STA)and/or user equipments (UE), communicate via a Radio Access Network(RAN) to one or more core networks (CN) of a wireless network. The RANcovers a geographical area which is divided into service areas or cellareas, which may also be referred to as a beam or a beam group, witheach service area or cell area being served by a radio network node suchas a radio access node e.g., a Wi-Fi access point or a radio basestation (RBS), which in some networks may also be denoted, for example,a “NodeB” or “eNodeB”. A service area or cell area is a geographicalarea where radio coverage is provided by the radio network node. Theradio network node communicates over an air interface operating on radiofrequencies with the wireless device within range of the radio networknode.

In this disclosure, the term “wireless device” is used to represent anycommunication entity capable of radio communication with a wirelessnetwork, such as a RAN, by sending and receiving radio signals. Forexample, the wireless device described herein may be a mobile telephone,a tablet, a laptop computer and/or a Machine-to-Machine, M2M, device,also known as Machine Type Communication, MTC, device. Another commongeneric term in this field is “User Equipment, UE” which is frequentlyused herein as a synonym for wireless device.

Further, the term “network node”, is used herein to represent any nodeof a wireless network, such as a RAN, that is operative to communicatewith a wireless device over a radio interface and to transmitinformation in various channels. The network node in this disclosure mayrefer to a base station, radio node, Node B, base transceiver station,access point, etc., which communicates radio signals with the wirelessdevice.

A Universal Mobile Telecommunications System (UMTS) is a thirdgeneration (3G) telecommunication network, which evolved from the secondgeneration (2G) Global System for Mobile Communications (GSM). The UMTSterrestrial radio access network (UTRAN) is essentially a RAN usingwideband code division multiple access (WCDMA) and/or High Speed PacketAccess (HSPA) for user equipments. In a forum known as the ThirdGeneration Partnership Project (3GPP), telecommunications supplierspropose and agree upon standards for third generation networks, andinvestigate enhanced data rate and radio capacity. In some RANs, e.g. asin UMTS, several radio network nodes may be connected, e.g., bylandlines or microwave, to a controller node, such as a radio networkcontroller (RNC) or a base station controller (BSC), which supervisesand coordinates various activities of the plural radio network nodesconnected thereto. This type of connection is sometimes referred to as abackhaul connection. The RNCs and BSCs are typically connected to one ormore core networks.

Specifications for the Evolved Packet System (EPS), also called a FourthGeneration (4G) network, have been completed within the 3rd GenerationPartnership Project (3GPP) and this work continues in the coming 3GPPreleases, for example to specify a Fifth Generation (5G) network. TheEPS comprises the Evolved Universal Terrestrial Radio Access Network(E-UTRAN), also known as the Long Term Evolution (LTE) radio accessnetwork, and the Evolved Packet Core (EPC), also known as SystemArchitecture Evolution (SAE) core network. E-UTRAN/LTE is a variant of a3GPP radio access network wherein the radio network nodes are directlyconnected to the EPC core network rather than to RNCs. In general, inE-UTRAN/LTE the functions of an RNC are distributed between the radionetwork nodes, e.g. eNodeBs in LTE, and the core network. As such, theRAN of an EPS has an essentially “flat” architecture comprising radionetwork nodes connected directly to one or more core networks, i.e. theyare not connected to RNCs. To compensate for the above, the E-UTRANspecification defines a direct interface between the radio networknodes, this interface being denoted the X2 interface. EPS denotes theEvolved 3GPP Packet Switched domain.

There has been much work in 3GPP lately on specifying technologies tohandle and support Machine-to-Machine (M2M) and/or Internet of Things(IoT) related use cases. Most recent work for 3GPP Release 13 includesenhancements to support Machine-Type Communications (MTC) with a new UEcategory M1 (Cat-M1), supporting reduced bandwidth of up to 6 PhysicalResource Blocks (PRBs), and Narrowband IoT (NB-IoT) work item specifyinga new radio interface (and UE category NB1, Cat-NB1).

LTE enhancements introduced in 3GPP Release 13 for MTC are here referredto as “eMTC”, including, but not limited to, support for bandwidthlimited UEs, Cat-M1, and support for coverage enhancements. This is toseparate discussion from NB-IoT, although the supported features aresimilar on a general level.

There are multiple differences between “legacy” LTE and the proceduresand channels defined for eMTC procedures, likewise for NB-IoT. Someimportant differences include a new Physical Downlink Control Channel(PDCCH), which is called MPDCCH when used in eMTC and NPDCCH when usedin NB-IoT. The term “legacy LTE” thus basically indicates LTE technologydeveloped prior to the above-mentioned LTE enhancements and eMTCprocedures were introduced.

In the LTE specifications, multicast and broadcast services have beenspecified under Multimedia Broadcast Multicast Services (MBMS) enablingtransmission of the same content to multiple UEs in a specified area atthe same time.

Neither Cat-M1 nor NB-IoT UEs support MBMS at the moment, and in 3GPPRel-14, the multicast service is currently being standardized. This isbecause, for many IoT use cases, multicast support would be a usefulfeature to employ. Example use cases may include transmission of afirmware update to a large number of sensors or other devices, orsending a specific command to a large number of actuators at the sametime. Currently, such transmissions and/or commands would need to betransmitted to each receiving UE separately using unicast. However,using multicast to transmit the same transmission and/or command to alarge number of UEs with a single transmission would reduce the timeneeded to deliver the message and the radio resources required, thusincreasing spectral efficiency. The multicast services may be realizedusing two different transmissions schemes, MBMS Single-Frequency Network(MBSFN) and Single-Cell Point-to-Multipoint (SC-PTM).

In SC-PTM part of the configuration and control information is sent overSingle-Cell Multicast Control Channel (SC-MCCH) logical channel, see3GPP TS 36.321, “Medium Access Control (MAC) protocol specification”,v13.1.0, March 2016. UEs are not expected to monitor this channelcontinuously, but an indication of change to this information isindicated using a Radio Network Temporary Identifier denoted SC-N-RNTI,which UEs are expected to monitor, see 3GPP TS 36.331, “Radio ResourceControl (RRC) protocol specification”, v13.1.0, March 2016.

The SC-MCCH is a logical channel defined in the MAC specification TS36.321. It is transmitted over DL-SCH transport channel which in turn istransmitted using PDCCH and PDSCH physical channels in legacy LTE. ForeMTC, the corresponding physical control channel is MPDCCH and forNB-IoT the corresponding physical channels would be NPDCCH and NPDSCH.

The SC-MCCH carries the SCPTMConfiguration RRC message see TS 36.331,which includes configuration information for the UEs to receive MBMSservice(s) using SC-MTCH logical channel(s).

For MBSFN part of the configuration and control, information is sentover the Multicast Control Channel (MCCH). Changes are indicated usingM-RNTI in this case.

At 3GPP RAN#70 meeting, a new work item named Narrowband IoT (NB-IoT)was approved. The objective in this work item is to specify a radioaccess for cellular internet of things (IoT) that addresses improvedindoor coverage, support for massive number of low throughput devices,and is not sensitive to delay, also enabling ultra-low device cost, lowdevice power consumption and (optimized) network architecture.

For NB-IoT, three different operation modes are defined, i.e.,stand-alone, guard-band, and in-band. In stand-alone mode, the NB-IoTsystem is operated in dedicated frequency bands. For in-band operation,the NB-IoT system can be placed inside the frequency bands used by thecurrent LTE system, while in the guard-band mode, the NB-IoT system canbe operated in the guard band used by the current (legacy) LTE system.NB-IoT can operate with a system bandwidth of 180 kHz. When multiplecarriers are configured, see R1-161548, “RAN1 agreements for Rel-13NB-1° T”, source WI rapporteur (Ericsson), 3GPP TSG-RAN WG1 Meeting #84,St. Julian's, Malta, February 15th-19th, 2016, several 180 kHz carriersmay be used, e.g., for increasing the system capacity, inter-cellinterference coordination, load balancing, etc.

In order to enable certain use cases that require more capacity thanusual, e.g., software or firmware upgrade of NB-IoT devices,multi-carrier operations may be used, see e.g. R1-161548. The NB-IoTdevices may then listen to system information on an anchor carrier, butwhen there is data to receive the communication may be moved to asecondary carrier.

In the current SC-PTM transmission mode, after reading the SC-MCCH, a UEis not expected to monitor the SC-MCCH continuously. If theSCPTMConfiguration RRC message, sent over SC-MCCH, changes, anindication of change to the SC-MCCH is indicated using SC-N-RNTI, whichthe UE is expected to monitor. The change of SC-MCCH can only occur atthe beginning of the SC-MCCH modification period. The change of SC-MCCHmay occur because of a change in the currently configured SC-MCCHs oraddition of a new SC-MCCH. If a UE detects the change of SC-MCCH, and ifit is interested in receiving a multicast service configured by theSC-MCCH, the UE needs to read the entire SC-MCCH again.

The above mentioned way works well in LTE to indicate changes of SC-MCCHsince LTE systems use relatively large bandwidth, and the UE can receivethe SC-MCCH within a relatively short time. Also, LTE UEs are usuallycapable of monitoring several channels at the same time. But for systemslike, e.g., eMTC or NB-IoT, due the coverage extension and reducedbandwidth, it usually takes relatively long time for the UE to receivethe same amount of information, especially when the eMTC or NB-IoT UEsare located in poor coverage. Also, since eMTC and NB-IoT UEs aretypically designed with low complexity, their ability of simultaneouslydecoding serval channels is very limited. This is then a problem for theabove mentioned way of indicating changes of SC-MCCH.

More specifically, if an eMTC or NB-IoT UE has been configured bySC-MCCH with an ongoing SC-MTCH transmission, according to conventionalprocedures, upon being noticed that SC-MCCH is changed, the UE needs toread the entire SC-MCCH again, even if its own SC-MTCH configuration isnot changed. Reading the SC-MCCH may take a long time, due to thereasons mentioned above. If the SC-MTCH configuration is not changed forthe UE, this operation is thus performed anyway, thereby consumingenergy in vain. It should be noted that one SC-MCCH may configureseveral SC-MTCHs in a cell.

In the procedure described in R1-1610968, “WF on search space for NB-1°T SC-PTM”, source Huawei, HiSilicon, ZTE, 3GPP TSG RAN WG1 Meeting#86bis, Lisbon, Portugal, Oct. 10-14, 2016, it is mentioned that SC-MCCHchange notifications can be indicated in the Downlink ControlInformation (DCI) scheduling SC-MCCH and/or the DCI scheduling SC-MTCH,details of what is indicated and how. The UE still needs to check outthese changes by reading the entire SC-MCCH after each suchnotification.

SUMMARY

It is an object of embodiments and examples described herein to addressat least some of the problems and issues outlined above. It is possibleto achieve this object and others by using a network node, a wirelessdevice and methods therein, as defined in the attached independentclaims.

According to one aspect, a method is performed by a network node in awireless network, for enabling a wireless device to obtain configurationinformation from a multicast control channel, e.g. the above-mentionedSC-MCCH, transmitted by the network node. In this method, the networknode transmits an indication of change of the multicast control channel,wherein the indication further indicates whether the wireless device isaffected by the change and needs to acquire or obtain the multicastcontrol channel or not. The network node further transmits the multicastcontrol channel as changed according to said indication.

According to another aspect, a network node is arranged to enable awireless device to obtain configuration information from a multicastcontrol channel, e.g. the above-mentioned SC-MCCH, transmitted by thenetwork node. The network node is configured to transmit an indicationof change of the multicast control channel, wherein the indicationfurther indicates whether the wireless device is affected by the changeand needs to acquire or obtain the multicast control channel or not. Theabove transmitting functionality may be realized by means of a firsttransmitting module in the network node. The network node is furtherconfigured to transmit the multicast control channel as changedaccording to said indication, which functionality may be realized bymeans of a second transmitting module in the network node.

According to another aspect, a method is performed by a wireless devicefor obtaining configuration information from a multicast controlchannel, e.g. the above-mentioned SC-MCCH, transmitted by a network nodein a wireless network. In this method, the wireless device receives anindication of change of the multicast control channel, wherein theindication further indicates whether the wireless device is affected bythe change and the wireless device needs to acquire or obtain themulticast control channel or not. The wireless device then acquires orobtains the multicast control channel when said indication indicatesthat the wireless device is affected by the change.

According to another aspect, a wireless device is arranged to obtainconfiguration information from a multicast control channel, e.g. theabove-mentioned SC-MCCH, transmitted by a network node in a wirelessnetwork. The wireless device is configured to receive an indication ofchange of the multicast control channel, wherein the indication furtherindicates whether the wireless device is affected by the change and thewireless device needs to acquire or obtain the multicast control channelor not. This functionality may be realized by means of a receivingmodule in the wireless device. The wireless device is also operable toacquire or obtain the multicast control channel when said indicationindicates that the wireless device is affected by the change. The latterfunctionality may be realized by means of an acquiring or obtainingmodule in the wireless device.

Advantages that may be achieved when implementing the above networknode, wireless device and methods include that the wireless device onlyneeds to acquire or obtain the multicast control channel if theindication indicates that the wireless device is affected by the change.Thereby, the wireless device will consume less energy for monitoring themulticast control channel, as compared to the above-described knownprocedures.

The above network node, wireless device and methods may be configuredand implemented according to different optional embodiments toaccomplish further features and benefits, to be described below.

A computer program is also provided which comprises instructions which,when executed on at least one processor, cause the at least oneprocessor to carry out either of the methods described above. A programcarrier containing the above computer program is further provided,wherein the program carrier is one of an electronic signal, an opticalsignal, a radio signal, or a computer readable storage medium.

BRIEF DESCRIPTION OF DRAWINGS

The solution will now be described in more detail by means of exemplaryembodiments and with reference to the accompanying drawings, in which:

FIG. 1 is a communication scenario illustrating a wireless network whereembodiments herein may be employed.

FIG. 2 is a diagram illustrating how different channel parameters may beindicated for radio communication in a legacy LTE network.

FIG. 3 is a flow chart illustrating a procedure in a network node,according to further possible embodiments.

FIG. 4 is a flow chart illustrating a procedure in a wireless device,according to further possible embodiments.

FIG. 5 is a block diagram illustrating an example of how a network nodemay be structured, according to further possible embodiments.

FIG. 6 is a block diagram illustrating an example of how a wirelessdevice may be structured, according to further possible embodiments.

FIG. 7 is a signaling diagram illustrating an example of how a wirelessdevice and a network node may operate when a regular or conventionalprocedure is employed.

FIG. 8 is a signaling diagram illustrating an example of how a wirelessdevice and a network node may operate when at least some of theembodiments herein are employed.

FIG. 9 is a signaling diagram illustrating another example of how awireless device and a network node may operate when at least some of theembodiments herein are employed.

DETAILED DESCRIPTION

Some embodiments herein may be used to provide an Enhanced SC-MCCHchange notification for Single-point to multi-points or multicast forcommunications related to e.g. Machine-Type Communications, eMTC,NB-IoT, multicast, networked society, feedback, coverage enhancement,MAC, RRC.

Embodiments herein provide a more efficient way to notify a wirelessdevice whether a change of SC-MCCH affects the wireless device, such asits current SC-MTCH(s)′ configuration(s). The wireless device does notneed to read the SC-MCCH again until the wireless device is affected bya change thereof, e.g. when its interested SC-MTCH(s)′ configuration(s)has changed.

For example, the embodiments allow wireless devices to refrain fromacquiring SC-MCCH when the changes in SC-MCCH do not affect its currentSC-MTCH configuration, e.g. when the changes do not affect one or moreMBMS services the wireless device is receiving by means of the SC-MTCH.In this way, power or energy consumption of the wireless device can bereduced by avoiding unnecessary acquisition of the SC-MCCH.

Embodiments herein can be used in a wireless network in general. FIG. 1is a schematic overview depicting a wireless network 100. The wirelessnetwork 100 may comprise one or more RANs and one or more CNs. Thewireless network 100 may use a number of different technologies, such asMTC with a new UE category M1, Cat-M1 supporting reduced bandwidth of upto 6 PRBs, and NB-IoT specifying a new radio interface and UE categoryNB1, Cat-NB1.

The wireless network 100 may use a further number of differenttechnologies, such as Wi-Fi, Long Term Evolution (LTE), LTE-Advanced,5G, Wideband Code Division Multiple Access (WCDMA), Global System forMobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE),Worldwide Interoperability for Microwave Access (WiMax), or Ultra MobileBroadband (UMB), just to mention a few possible implementations.

Embodiments herein may relate to recent technology trends that are ofparticular interest in a 5G context, however, the embodiments are alsoapplicable in further development of the existing wireless communicationsystems such as e.g. WCDMA and LTE.

Network nodes operate in the wireless network 100 such as a network node110. The network node 110 provides radio coverage over a geographicalarea 11, which may also be called a service area or a cell or a beam ora beam group where the group of beams is covering the service area of afirst radio access technology (RAT), such as 5G, LTE, Wi-Fi or similar.12 denotes another geographical area of radio coverage provided by thenetwork node 110.

The network node 110 may be a transmission and reception point e.g. aradio access network node such as a Wireless Local Area Network (WLAN)access point or an Access Point Station (AP STA), an access controller,a base station, e.g. a radio base station such as BSS, a NodeB, anevolved Node B (eNB, eNode B), a base transceiver station, a radioremote unit, an Access Point Base Station, a base station router, atransmission arrangement of a radio base station, a stand-alone accesspoint or any other network unit capable of communicating with a wirelessdevice within the service area served by the respective network nodedepending e.g. on the radio access technology and terminology used.

In the wireless network 100, UEs such as a wireless device 120,communicate via one or more Access Networks (AN), e.g. RAN, to one ormore core networks (CN). It should be understood by one skilled in theart that “wireless device” is a non-limiting term which for examplemeans any eMTC UE, Cat-M1 UE, NB-IoT UE, terminal, wirelesscommunication terminal, user equipment, Machine Type Communication (MTC)device, Device to Device (D2D) terminal, or node e.g. smart phone,laptop, mobile phone, sensor, relay, mobile tablets or even a small basestation communicating within a cell.

In the following, various embodiments will be described and explained bymeans of some illustrative but non-limiting examples. It should be notedthat these embodiments and examples are not mutually exclusive and canbe combined whenever suitable. For example, components from oneembodiment may be tacitly assumed to be applicable in combination withanother embodiment and it will be obvious to a person skilled in the arthow those components may be used in other exemplary embodiments.

As mentioned in the background section, a SC-PTM has two importantchannels, i.e., SC-MCCH and SC-MTCH. FIG. 2 shows the legacy LTE Rel-13SC-PTM work procedures. From FIG. 2 it can be seen that in a cell thereis only one SC-MCCH that configures several SC-MTCHs which offersdifferent multicast services. The payload of SC-MCCH and SC-MPTCH arecarried by shared data channels, and scheduled by using Downlink ControlInformation (DCI). Currently, for eMTC a DCI is carried by theabove-mentioned channel MPDCCH and for NB-IoT a DCI is carried by theabove-mentioned channel NPDCCH. The DCI format used for eMTC and NB-10TSC-PTM has presently not been decided in 3GPP.

Due to a difference between LTE and eMTC/NB-IoT systems, it is agreed in“DRAFT Report from the IoT breakout sessions, 3GPP RAN2 Meeting #95bis,Kaohsiung, Taiwan, Oct. 10-14, 2016″ that” RAN2 assumes that directIndication or similar mechanism, that provides information in DCI, maybe used for SC-MCCH change notification. Therefore, the legacy way,i.e., REL-13 SC-PMT, of SC-MCCH change notification is modified. Andbecause of this change, there will be associated overhead if theeMTC/NB-IoT UEs use the legacy way to obtained the changes of SC-MCCH.

According to embodiments herein, several difference ways of using one ormaybe more fields in the DCIs are provided to better indicate thechanges in SC-MCCH configurations. According to embodiments herein, thenetwork, such as the network node 110 provides addition information inthe DCIs together with SC-MCCH change notification to assist a UE suchas the wireless device 120, to decide whether or not the changenotification is relevant to the wireless device 120, and decides whetheror not to read the entire new SC-MCCH. The previously mentioned DCIs mayinclude the DCI used for the direct indication of SC-MCCH changenotification, or DCIs which schedule the SC-MCCH and/or SC-MTCH payload.

A non-limiting example of how a network node may operate is illustratedby the flow chart in FIG. 3 which will now be described with furtherreference to FIG. 1 but without limitation to the communication scenarioin FIG. 1. FIG. 3 thus illustrates a procedure in the network node, suchas the network node 110, for enabling a wireless device, such as thewireless device 120, to obtain configuration information from amulticast control channel, e.g. the above-mentioned SC-MCCH, transmittedby the network node.

A first action 301 illustrates that the network node 200 transmits anindication of change of the multicast control channel, wherein theindication further indicates whether the wireless device is affected bythe change and needs to acquire or obtain the multicast control channelor not. Some examples of how this indication may be transmitted will bepresented below. The network node further transmits the multicastcontrol channel as changed according to said indication, in an action302. Thereby, it is an advantage that the wireless device can decide toobtain and acquire the multicast control channel only if it is affectedby the change and to refrain when not affected, which will reduce energyconsumption in the wireless device as explained above.

Some optional and non-limiting embodiments of the above procedure in thenetwork node will now be described. In one example embodiment, theindication may indicate whether a configuration of a multicast trafficchannel, e.g. the above-mentioned SC-MTCH, used by the wireless deviceis changed. In another example embodiment, the indication may betransmitted by means of a Radio Network Temporary Identifier, RNTI.

In another example embodiment, the indication may be transmitted asinformation in Downlink Control Information, DCI, that is used toschedule different multicast traffic channels (SC-MTCHs), saidinformation indicating whether a configuration of respective multicasttraffic channels is changed or not. An example of how this embodimentmay be employed will be described later with reference to FIG. 8. Inthis case, another example embodiment may be that said informationindicates that a new service is established or that an old, i.e. currentor existing, service is changed for the respective multicast trafficchannels.

In another example embodiment, the indication is transmitted asinformation in Downlink Control Information, DCI, that is used toschedule payload in the multicast control channel (SC-MCCH), saidinformation indicating whether a configuration of multicast trafficchannels is changed or not. An example of how this embodiment may beemployed will also be described later with reference to FIG. 9.

In another example embodiment, the indication may be transmitted asinformation in a direct indication message, said information indicatingwhich multicast traffic channel configuration(s) is/are changed.

In a further example embodiment, the indication may indicate whether thechange comprises at least one of: establishment of new multicast trafficchannel configuration(s) and update of old, i.e. current or existing,multicast traffic channel configuration(s).

Another non-limiting example of how a wireless device, such as thewireless device 120, may operate is further illustrated by the flowchart in FIG. 4 which will now be described likewise with furtherreference to FIG. 1. FIG. 4 thus illustrates a procedure in the wirelessdevice 120 for obtaining configuration information from a multicastcontrol channel (SC-MCCH) transmitted by a network node (110) in awireless network.

A first action 401 illustrates that the wireless device 120 receives,from the network node, an indication of change of the multicast controlchannel, wherein the indication further indicates whether the wirelessdevice is affected by the change and the wireless device needs toacquire or obtain the multicast control channel or not. This actioncorresponds to action 301 above. In a next action 402, the wirelessdevice 120 acquires or obtains the multicast control channel when saidindication indicates that the wireless device is affected by the change.Otherwise, the wireless device 120 does not need to acquire or obtainthe multicast control channel which will save energy, i.e. battery, inthe device which is an advantage as explained above.

Some optional and non-limiting embodiments of the above procedure in thenetwork node will now be described. In one example embodiment, theindication may indicate whether a configuration of a multicast trafficchannel (SC-MTCH) used by the wireless device is changed. In anotherexample embodiment, the indication may be received by means of a RadioNetwork Temporary Identifier, RNTI.

In another example embodiment, the indication is received as informationin Downlink Control Information, DCI, that is used to schedule differentmulticast traffic channels (SC-MTCHs), said information indicatingwhether a configuration of respective multicast traffic channels ischanged or not. In another example embodiment, said information may inthat case indicate that a new service is established or that an old,i.e. current or existing, service is changed for the respectivemulticast traffic channels.

In another example embodiment, the indication may be received asinformation in Downlink Control Information, DCI, that is used toschedule payload in the multicast control channel (SC-MCCH), saidinformation indicating whether a configuration of multicast trafficchannels is changed or not.

In another example embodiment, the indication may be received asinformation in a direct indication message, said information indicatingwhich multicast traffic channel configuration(s) is/are changed.

In another example embodiment, the indication may indicate whether thechange comprises at least one of: establishment of new multicast trafficchannel configuration(s) and update of old, i.e. current or existing,multicast traffic channel configuration(s).

The block diagrams in FIGS. 5 and 6 illustrate how a network node 500and a wireless device 600, respectively, may be structured to bringabout the above-described solution and embodiments thereof. In thesefigures, the network node 500 and the wireless device 600 may beconfigured to operate according to any of the examples and embodimentsof employing the solution as described herein, where appropriate,particularly in the manner described above for FIGS. 3 and 4,respectively. Each of the network node 500 and the wireless device 600is shown to comprise a processor and a memory.

Each of the network node 500 and the wireless device 600 furthercomprises equipment configured for communication with each other using asuitable protocol for the communication depending on the implementation.The solution is however not limited to any specific types of radiosignals or protocols.

The network node 500 is, e.g. by means of units, modules or the like,configured or arranged to perform the actions of the flow chart in FIG.3 as follows. Further, the wireless device 600 is, e.g. by means ofunits, modules or the like, configured or arranged to perform theactions of the flow chart in FIG. 4 as follows.

With reference to FIG. 5, the network node 500 is arranged to enable awireless device to obtain configuration information from a multicastcontrol channel, e.g. the SC-MCCH, transmitted by the network node 500.

The network node 500 is configured to transmit an indication of changeof the multicast control channel, wherein the indication furtherindicates whether the wireless device is affected by the change andneeds to acquire or obtain the multicast control channel or not. Thisoperation may be performed by a first transmitting module 500A in thenetwork node 500 and as illustrated in action 301. The network node 500is also configured to transmit the multicast control channel as changedaccording to said indication. This operation may be performed by asecond transmitting module 500B in the network node 500 and asillustrated in action 302.

With reference to FIG. 6, the wireless device 600 is arranged to obtainconfiguration information from a multicast control channel, e.g. theSC-MCCH, transmitted by a network node in a wireless network.

The wireless device 600 is configured to receive, from the network node,an indication of change of the multicast control channel, wherein theindication further indicates whether the wireless device is affected bythe change and the wireless device needs to acquire or obtain themulticast control channel or not. This operation may be performed by areceiving module 600A in the wireless device 600 and as illustrated inaction 401.

The wireless device 600 is also configured to acquire or obtain themulticast control channel when said indication indicates that thewireless device is affected by the change. This operation may beperformed by an acquiring/obtaining module 600B in the wireless device600 and as illustrated in action 402.

It should be noted that FIGS. 5 and 6 illustrate various functionalmodules in the network node 500 and the wireless device 600,respectively, and the skilled person is able to implement thesefunctional modules in practice using suitable software and hardwareequipment. Thus, the solution is generally not limited to the shownstructures of the network node 500 and the wireless device 600, and thefunctional modules therein may be configured to operate according to anyof the features, examples and embodiments described in this disclosure,where appropriate.

The functional modules 500A-B and 600A-B described above may beimplemented in the network node 500 and the wireless device 600,respectively, by means of program modules of a respective computerprogram comprising code means which, when run by the processor P causesthe network node 500 and the wireless device 600 to perform theabove-described actions and procedures. Each processor P may comprise asingle Central Processing Unit (CPU), or could comprise two or moreprocessing units. For example, each processor P may include a generalpurpose microprocessor, an instruction set processor and/or relatedchips sets and/or a special purpose microprocessor such as anApplication Specific Integrated Circuit (ASIC). Each processor P mayalso comprise a storage for caching purposes.

Each computer program may be carried by a computer program product ineach of the network node 500 and the wireless device 600 in the form ofa memory having a computer readable medium and being connected to theprocessor P. The computer program product or memory M in each of thenetwork node 500 and the wireless device 600 thus comprises a computerreadable medium on which the computer program is stored e.g. in the formof computer program modules or the like. For example, the memory M ineach node may be a flash memory, a Random-Access Memory (RAM), aRead-Only Memory (ROM) or an Electrically Erasable Programmable ROM(EEPROM), and the program modules could in alternative embodiments bedistributed on different computer program products in the form ofmemories within the respective network node 500 and wireless device 600.

The solution described herein may be implemented in each of the networknode 500 and the wireless device 600 by a computer program comprisinginstructions which, when executed on at least one processor, cause theat least one processor to carry out the actions according to any of theabove embodiments and examples, where appropriate. The solution may alsobe implemented at each of the network node 500 and the wireless device600 in a carrier containing the above computer program, as shown in thefigures, wherein the carrier is one of an electronic signal, opticalsignal, radio signal, or computer readable storage medium.

Some further examples of how the embodiments herein may be implementedwill now be described in terms of four possible implementations 1-4which are related to at least some of the above-described embodiments.Note that the multicast control channels used in the examples below areexemplified with the SC-MCCH, however, also other types of multicastcontrol channels may be used in the embodiments herein. Furthermore,multicast traffic channels used in the examples below are exemplifiedwith the SC-MTCH, however, also other types of multicast trafficchannels may be used in the embodiments herein.

First Implementation

This implementation refers to the above embodiment where the indicationis transmitted as information in a DCI that is used to scheduledifferent multicast traffic channels e.g. SC-MTCHs, said informationindicating whether a configuration of respective multicast trafficchannels is changed or not.

It is agreed in “DRAFT Report from the IoT breakout sessions, 3GPP RAN2Meeting #95bis, Kaohsiung, Taiwan, Oct. 10-14, 2016” that “RAN2 assumesthat direct Indication or similar mechanism (that provides informationin DCI) can be used for SC-MCCH change notification.” Therefore, at thetime when the network indicates the change of SC-MCCH, it may alsoinclude necessary information in the DCIs that schedules differentSC-MTCHs, and also indicates whether the configuration of a particularSC-MTCH is changed.

In more detail, each SC-MTCH payload transmission on the common shareddata channel is scheduled by an SC-MTCH control channel carrying a DCI.As mentioned above, for eMTC a DCI is carried by MPDCCH and for NB-IoT aDCI is carried by NPDCCH. Therefore, upon receiving or detecting anSC-MCCH change notification, the network node 110 may indicate in aSC-MTCH DCI whether the configuration of the corresponding SC-MTCH isgoing to be changed or not. If the DCI indicates the configuration ofthis SC-MTCH is going to be changed, the UE such as the wireless device120 will go and read the updated SC-MCCH.

Otherwise, the UE can still assume that the previous configuration isvalid. For example, see FIG. 2, in the DCI for SC-MTCH 1, if this DCIindicates the configuration of SC-MTCH 1 is not changed, then UEs suchas the wireless device 120 that are currently listening to SC-MTCH 1 donot need to read the updated SC-MCCH, and vice versa.

Furthermore, the network node 110 may indicate in the DCIs whether thechange of SC-MCCH includes to add in new services rather than change ofold services. DCIs here means different DCIs that schedules differentSC-MTCHs. In this case, the UEs such as the wireless device 120 thathave interests in new services can go and read the updated SC-MCCH, andthe ones that are not interested can assume that their currentSC-MTCH(s)′ configuration(s) are not changed.

An example of how the first implementation may be realized in practicewill be described later with reference to FIG. 8.

Second Implementation

This implementation refers to the above embodiment where the indicationis transmitted as information in a DCI that is used to schedule payloadin the multicast control channel e.g. SC-MCCH, said informationindicating whether a configuration of multicast traffic channels ischanged or not. This is similar to the first implementation, but insteadof indicating the SC-MTCH change in DCIs that schedule differentSC-MTCHs, the change information may thus be provided in the DCI thatschedules the SC-MCCH payload.

The DCI that schedules the SC-MCCH payload may indicate that the changeof SC-MCCH is related to whether the configurations of some specificSC-MTCHs are changed. And UEs such as e.g. the wireless device 120 thatare affected will thereby proceed to read the updated SC-MCCH.

Further, in the DCI that schedules the SC-MCCH payload, the network node110 may also indicate whether or not the change of SC-MCCH includesadding new services, e.g., new SC-MTCH configurations, or if it is anupdate of the old SC-MTCH configurations, or both. Then, if the changeof SC-MCCH is just about adding in new services, a UE such as e.g. thewireless device 120 may assume its old SC-MTCH configurations are notchanged. In this case, only if a UE that is interested in the newlyadded service it will go and read the SC-MCCH changes.

In one example of the second implementation, a bit field of length N inthe DCI may be used to indicate, e.g. by using a bit map, which specificSC-MTCHs or MBMS services that have been changed. The UE such as e.g.the wireless device 120 listening to the corresponding changedSC-MTCH(s) may then re-acquire the SCPTMConfiguration message carriedover SC-MCCH. In another example of the second implementation, there maybe a field in the DCI which can be used to indicate whether there arenew services or some existing services that have stopped in the updatedconfiguration message, e.g. in case RAN2 introduces a means to indicatesuch to the UE such as e.g. the wireless device 120 via a MAC CE. It isalso possible to combine the above two examples of the secondImplementation so that there is one field or flag indicating newmessages and another field indicating the specific changed configurationinformation.

An example of how the second implementation may be realized in practicewill be described later with reference to a signaling procedure which isillustrated in FIG. 9.

Third Implementation

This implementation refers to the above embodiment where the indicationis transmitted as information in a direct indication message, saidinformation indicating which multicast traffic channel configuration(s)is/are changed.

It is agreed in DRAFT Report from the IoT breakout sessions, 3GPP RAN2Meeting #95bis, Kaohsiung, Taiwan, Oct. 10-14, 2016 that “RAN2 assumesthat direct Indication or similar mechanism (that provides informationin DCI) may be used for SC-MCCH change notification. Therefore, in thedirect indication message, in addition to notifying that the SC-MCCHconfiguration will be changed, it is also possible to includeinformation about which SC-MTCHs or MBMS services are affected by thechange. In this way, upon receiving the change indication, a UE such ase.g. the wireless device 120 may decide whether to re-acquire theSC-MCCH or not.

Fourth Implementation

This implementation refers to the above embodiment where the indicationindicates whether the change comprises at least one of: establishment ofnew multicast traffic channel configuration(s) and update of old, i.e.current or existing, multicast traffic channel configuration(s).

In some cases, the third Implementation may not be practicable, as, forexample, indicating different services may mean increasing theindication size too much. If so, the fourth implementation may be usedto simply indicate that the change of SC-MCCH includes to add newservices, e.g., new SC-MCTCH configurations, or that it is an update ofthe old SC-MTCH configurations, or both. Then, if the change of SC-MCCHis just about adding in new services, a UE such as e.g. the wirelessdevice 120 may assume that its old SC-MTCH configurations have notchanged. In this case, only a UE such as e.g. the wireless device 120that is interested in the newly added service will go and read theSC-MCCH changes.

In the case of just the addition of new services is indicated, then itis enough to use one additional field to indicate this addition of newservices. Or a combination of several fields may be used for thispurpose.

In addition, if the change of SC-MCCH is related to removing one orseveral ongoing services, this change can also be reflected in the sameway as mentioned above. The UEs, such as e.g. the wireless device 120,that may have ongoing SC-MTCH(s) will go and read the SC-MCCH for thechanges, but the UEs, such as e.g. the wireless device 120, that areonly monitoring some SC-PTM service and have no ongoing SC-MTCH(s) donot need to go and read the SC-MCCH changes.

Two examples of how the solution may be realized in practice will bedescribed below with reference to the signaling diagrams in FIGS. 8 and9. First, an example of a conventional procedure where the inventiveindication is not used will be described with reference to the signalingdiagram in FIG. 7 as a comparison. In this procedure it is assumed thatthe network node provides a particular service by transmitting payloadon a multicast traffic channel “SC-MTCH #1”, and that a wireless deviceis configured to employ the service by monitoring the SC-MTCH #1. Theprocedure includes the following course of actions:

Action 7:1—The network node periodically broadcasts a System InformationBlock called “SIB20” which contains a configuration of the multicastcontrol channel SC-MCCH.

Action 7:2—The wireless device receives the SIB20 and obtains theconfiguration of SC-MCCH therefrom.

Action 7:3—The network node transmits a DCI on the PDCCH, which DCIschedules the network node's transmissions of the SC-MCCH. By receivingthis DCI, the wireless device will know when to receive and monitor theSC-MCCH.

Action 7:4—The network node transmits the SC-MCCH according to thescheduling indicated in the DCI of action 7:3, which SC-MCCH is receivedby the wireless device.

Action 7:5—The wireless device obtains from the SC-MCCH a configurationof the specific SC-MTCH #1 which is thus of interest to the wirelessdevice to employ the service.

Action 7:6—The network node transmits a DCI on the PDCCH, which DCIschedules the network node's transmissions of the SC-MTCH #1. Thereby,the wireless device will know when to receive the SC-MTCH #1.

Action 7:7—The network node transmits the SC-MTCH #1 according to thescheduling indicated in the DCI of action 7:6, which SC-MTCH #1 isreceived by the wireless device.

It should be noted that the wireless device needs to keep monitoring theSC-MCCH by repeating at least actions 7:3-7:5, in case there is anychange of the configuration of the SC-MTCH #1, which consequently drainsthe wireless device's battery.

The signaling diagram in FIG. 8 illustrates an example of how theabove-described “first implementation” may be realized in practice,which will now be described in terms of the following course of actions.In this implementation, the indication of change of the multicastcontrol channel is thus transmitted as information in a DCI that is usedto schedule different multicast traffic channels or SC-MTCHs, saidinformation indicating whether a configuration of respective multicasttraffic channels is changed or not.

In this procedure, it is again assumed that the network node provides aparticular service by transmitting payload on the SC-MTCH #1, and thatthe wireless device is configured to receive and monitor the SC-MTCH #1to employ the service. It is also assumed that the wireless device hasobtained a configuration of the SC-MTCH #1, e.g. as described above forFIG. 7. The procedure of FIG. 8 is as follows:

Action 8:1—The network node transmits a DCI on the PDCCH, which DCIschedules the network node's transmissions of the SC-MTCH #1. Thereby,the wireless device will know when to receive the SC-MTCH #1.

Action 8:2—The network node transmits the SC-MTCH #1 according to thescheduling indicated in the DCI of action 8:1, which SC-MTCH #1 isreceived by the wireless device. These first two actions correspond toactions 7:6 and 7:7 in the above conventional procedure which may berepeated until the next actions occur.

Action 8:3—The network node finds out that the configuration of SC-MTCH#1 will be changed which means that the SC-MCCH will also be changedaccordingly.

Action 8:4—The network node transmits a DCI on the PDCCH, which DCIschedules the network node's transmissions of the SC-MTCH #1. In thiscase, the DCI also contains an indication of change of the configurationof SC-MTCH #1 in the SC-MCCH which configuration will be valid in aforthcoming next modification period, e.g. by setting a changeindication bit in the DCI for that SC-MTCH #1. Thereby, the wirelessdevice will know that it is affected by the SC-MCCH change and thereforeneeds to read the SC-MCCH again in the next modification period.

Action 8:5—The network node transmits the SC-MTCH #1 with the “old”configuration of SC-MTCH #1 which has thus not yet changed, and thewireless device is thereby able to obtain this SC-MTCH #1 transmissionwith the old configuration.

Action 8:6—The network node now changes the configuration of SC-MTCH #1which means that the SC-MCCH is also changed accordingly.

Action 8:7—The network node transmits a DCI on the PDCCH, which DCIschedules the network node's transmissions of the SC-MCCH, as in action7:3. By receiving this DCI, the wireless device will know when tomonitor the SC-MCCH and can thereby obtain the changed configuration ofSC-MTCH #1 as follows.

Action 8:8—The network node transmits the SC-MCCH according to thescheduling indicated in the DCI of action 8:7, which SC-MCCH is receivedby the wireless device, as in action 7:4.

Action 8:9—The wireless device obtains from the SC-MCCH the new, i.e.changed, configuration of the SC-MTCH #1. Thereby, the wireless deviceis able to receive and use the SC-MTCH #1 when transmitted from thenetwork node.

It should be noted that in this case the wireless device does not needto monitor the SC-MCCH unless a change of the configuration of theSC-MTCH #1 is indicated in the DCI for SC-MTCH #1 of action 8:4, whichthereby reduces the wireless device's energy consumption.

The signaling diagram in FIG. 9 illustrates an example of how theabove-described “second implementation” may be realized in practice,which will now be described in terms of the following course of actions.In this implementation, the indication of change of the multicastcontrol channel is thus transmitted as information in a DCI that is usedto schedule payload in the multicast control channel or SC-MCCH, saidinformation indicating whether a configuration of multicast trafficchannels is changed or not.

When this procedure starts, it is assumed that the network node does notyet provide a service by transmitting payload on the SC-MTCH #1, andthat the wireless device is configured to receive and monitor theSC-MTCH #1 to employ the service once it becomes available. Theprocedure of FIG. 9 is as follows:

Action 9:1—The network node periodically broadcasts a System InformationBlock called “SIB20” which contains a configuration of the multicastcontrol channel SC-MCCH.

Action 9:2—The wireless device receives the SIB20 and obtains theconfiguration of SC-MCCH therefrom.

Action 9:3—The network node transmits a DCI on the PDCCH, which DCIschedules the network node's transmissions of the SC-MCCH. By receivingthis DCI, the wireless device will know when to monitor the SC-MCCH.

Action 9:4—The network node transmits the SC-MCCH according to thescheduling indicated in the DCI of action 7:3, which SC-MCCH is receivedby the wireless device. So far, actions 9:1-9:4 correspond to actions7:1-7:4 in the conventional procedure of FIG. 7.

Action 9:5—The network node finds out that a configuration of SC-MTCH #1is created for the service, which means that the SC-MCCH will also bechanged accordingly.

Action 9:6—The network node transmits a DCI on the PDCCH, which DCIschedules the network node's transmissions of the SC-MCCH. In this case,the DCI also contains an indication of the created configuration ofSC-MTCH #1 in the SC-MCCH, e.g. by setting a change indication bit inthe DCI for that SC-MTCH #1. Thereby, the wireless device will know thatit is affected by the SC-MCCH change and therefore needs to read theSC-MCCH to obtain the configuration of SC-MTCH #1.

Action 9:7—The network node transmits the SC-MCCH according to thescheduling indicated in the DCI of action 9:6, which SC-MCCH is receivedby the wireless device.

Action 9:8—The wireless device obtains from the SC-MCCH theconfiguration of the SC-MTCH #1. Thereby, the wireless device is able toreceive and use the SC-MTCH #1 when transmitted from the network node.

Action 9:9—The network node transmits a DCI on the PDCCH, which DCIschedules the network node's transmissions of the SC-MTCH #1. Thereby,the wireless device will know when to receive the SC-MTCH #1.

Action 9:10—The network node transmits the SC-MTCH #1 according to thescheduling indicated in the DCI of action 7:6, which SC-MTCH #1 isreceived by the wireless device.

It should be noted that in this case the wireless device does not needto monitor the SC-MCCH unless the DCI for the SC-MCCH of action 9:6indicates that the configuration of the SC-MTCH #1 is available, whichthereby reduces the wireless device's energy consumption.

As used herein, the term “processing module” may refer to a processingcircuit, a processing unit, a processor, an Application Specificintegrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or thelike. As an example, a processor, an ASIC, an FPGA or the like maycomprise one or more processor kernels. In some examples, the processingmodule may be embodied by a software module or hardware module. Any suchmodule may be a determining means, estimating means, capturing means,associating means, comparing means, identification means, selectingmeans, receiving means, transmitting means or the like as disclosedherein. As an example, the expression “means” may be a module, such as adetermining module, selecting module, etc.

As used herein, the expression “configured to” may mean that aprocessing circuit is configured to, or adapted to, by means of softwareconfiguration and/or hardware configuration, perform one or more of theactions described herein.

As used herein, the term “memory” may refer to a hard disk, a magneticstorage medium, a portable computer diskette or disc, flash memory,random access memory (RAM) or the like. Furthermore, the term “memory”may refer to an internal register memory of a processor or the like.

As used herein, the term “computer readable medium” may be a UniversalSerial Bus (USB) memory, a DVD-disc, a Blu-ray disc, a software modulethat is received as a stream of data, a Flash memory, a hard drive, amemory card, such as a Memory Stick, a Multimedia Card (MMC), etc.

As used herein, the term “computer readable code units” may be text of acomputer program, parts of or an entire binary file representing acomputer program in a compiled format or anything there between.

As used herein, the terms “number”, “value” may be any kind of digit,such as binary, real, imaginary or rational number or the like.Moreover, “number”, “value” may be one or more characters, such as aletter or a string of letters. “Number”, “value” may also be representedby a bit string.

As used herein, the expression “in some embodiments” has been used toindicate that the features of the embodiment described may be combinedwith any other embodiment disclosed herein.

When using the word “comprise” or “comprising” it shall be interpretedas non-limiting, i.e. meaning “consist at least of”.

Abbreviation Explanation

-   -   DCI Downlink Control Information    -   NB Narrow band    -   NB-IoT Narrowband Internet of Things    -   MTC Machine Type Communications    -   LTE Long Term Evolution    -   PDCCH Physical Data Control Channel    -   NB-PBCH NB-IoT Physical Broadcast Channel    -   PRB Physical Resource Block    -   DL Downlink    -   UL Uplink    -   RRC Radio Resource Control    -   SC-MCCH Single-cell multicast control channel    -   SC-MTCH Single-cell multicast traffic channel    -   RNTI Radio Network Temporary Identifier    -   MBMS Multimedia Broadcast Multicast Services    -   MAC Medium Access Control

While the solution has been described with reference to specificexemplifying embodiments, the description is generally only intended toillustrate the inventive concept and should not be taken as limiting thescope of the solution. For example, the terms “network node”, “wirelessdevice”, “indication of change”, “multicast control channel” and“multicast traffic channel” have been used throughout this disclosure,although any other corresponding entities, functions, and/or parameterscould also be used having the features and characteristics describedhere. The solution may be implemented according to the appended claimswhich contain references in parenthesis to corresponding actions inFIGS. 3 and 4 and to corresponding modules in FIGS. 5 and 6.

1-66. (canceled)
 67. A method performed by a network node in a wirelessnetwork, for enabling a wireless device to obtain configurationinformation from a multicast control channel (SC-MCCH) transmitted bythe network node, the method comprising: transmitting an indication of achange of the multicast control channel, wherein the indication furtherindicates whether the wireless device is affected by the change andneeds to acquire or obtain the multicast control channel; andtransmitting the multicast control channel as changed according to theindication.
 68. The method according to claim 67, wherein the indicationindicates whether a configuration of a multicast traffic channel(SC-MTCH) used by the wireless device is changed.
 69. The methodaccording to claim 67, wherein the indication is transmitted by means ofa Radio Network Temporary Identifier (RNTI).
 70. The method according toclaim 67, wherein the indication is transmitted as information inDownlink Control Information (DCI) that is used to schedule differentmulticast traffic channels (SC-MTCHs), the information indicatingwhether a configuration of respective multicast traffic channels ischanged.
 71. The method according to claim 70, wherein the informationindicates one of: a new service is established; and an existing serviceis changed for the respective multicast traffic channels.
 72. The methodaccording to claim 67, wherein the indication is transmitted asinformation in Downlink Control Information (DCI) that is used toschedule payload in the multicast control channel, the informationindicating whether a configuration of multicast traffic channels ischanged.
 73. The method according to claim 67, wherein the indication istransmitted as information in a direct indication message, theinformation indicating which multicast traffic channel configurationsare changed.
 74. The method according to claim 67, wherein theindication indicates whether the change comprises at least one of:establishment of new multicast traffic channel configurations; andupdate of existing multicast traffic channel configurations.
 75. Anetwork node configured to enable a wireless device to obtainconfiguration information from a multicast control channel (SC-MCCH)transmitted by the network node, wherein the network node comprises:communication circuitry configured for communicating with the wirelessdevice; and processing circuitry operatively associated with thecommunication circuitry and configured to: transmit an indication of achange of the multicast control channel, wherein the indication furtherindicates whether the wireless device is affected by the change andneeds to acquire or obtain the multicast control channel; and transmitthe multicast control channel as changed according to the indication.76. The network node according to claim 75, wherein the indicationindicates whether a configuration of a multicast traffic channel(SC-MTCH) used by the wireless device is changed.
 77. The network nodeaccording to claim 75, wherein the processing circuitry is configured totransmit the indication by means of a Radio Network Temporary Identifier(RNTI).
 78. The network node according to claim 75, wherein theprocessing circuitry is configured to transmit the indication asinformation in Downlink Control Information (DCI) that is used toschedule different multicast traffic channels (SC-MTCHs), theinformation indicating whether a configuration of multicast trafficchannels is changed.
 79. The network node according to claim 78, whereinthe information indicates one of: a new service is established; and anexisting service is changed for the respective multicast trafficchannels.
 80. The network node according to claim 75, wherein theprocessing circuitry is configured to transmit the indication asinformation in Downlink Control Information (DCI) that is used toschedule payload in the multicast control channel, the informationindicating whether a configuration of respective multicast trafficchannels is changed.
 81. The network node according to claim 75, whereinthe processing circuitry is configured to transmit the indication asinformation in a direct indication message, the information indicatingwhich multicast traffic channel configurations are changed.
 82. Thenetwork node according to claim 75, wherein the indication indicateswhether the change comprises at least one of: establishment of newmulticast traffic channel configurations; and update of existingmulticast traffic channel configurations.
 83. A method performed by awireless device for obtaining configuration information from a multicastcontrol channel (SC-MCCH) transmitted by a network node in a wirelessnetwork, the method comprising: receiving an indication of a change ofthe multicast control channel, wherein the indication further indicateswhether the wireless device is affected by the change and needs toacquire or obtain the multicast control channel; and acquiring orobtaining the multicast control channel responsive to determining thatthe indication indicates that the wireless device is affected by thechange.
 84. The method according to claim 83, wherein the indicationindicates whether a configuration of a multicast traffic channel(SC-MTCH) used by the wireless device is changed.
 85. The methodaccording to claim 83, wherein the indication is received by means of aRadio Network Temporary Identifier (RNTI).
 86. The method according toclaim 83, wherein the indication is received as information in DownlinkControl Information (DCI) that is used to schedule different multicasttraffic channels (SC-MTCHs), the information indicating whether aconfiguration of respective multicast traffic channels is changed. 87.The method according to claim 86, wherein the information indicates oneof: a new service is established; and an existing service is changed forthe respective multicast traffic channels.
 88. The method according toclaim 83, wherein the indication is received as information in DownlinkControl Information (DCI) that is used to schedule payload in theSC-MCCH, the information indicating whether a configuration of multicasttraffic channels is changed.
 89. The method according to claim 83,wherein the indication is received as information in a direct indicationmessage, the information indicating which multicast traffic channelconfigurations are changed.
 90. The method according to claim 83,wherein the indication indicates whether the change comprises at leastone of: establishment of new multicast traffic channel configurations;and update existing multicast traffic channel configurations.
 91. Awireless device configured to obtain configuration information from amulticast control channel (SC-MCCH) transmitted by a network node in awireless network, wherein the wireless device comprises: communicationcircuitry configured for communicating with the network node; andprocessing circuitry operatively associated with the communicationcircuitry and configured to: receive an indication of a change of themulticast control channel, wherein the indication further indicateswhether the wireless device is affected by the change and needs toacquire or obtain the multicast control channel; and acquire or obtainthe multicast control channel responsive to determining that theindication indicates that the wireless device is affected by the change.92. The wireless device according to claim 91, wherein the indicationindicates whether a configuration of a multicast traffic channel(SC-MTCH) used by the wireless device is changed.
 93. The wirelessdevice according to claim 91, wherein the processing circuitry isconfigured to receive the indication by means of a Radio NetworkTemporary Identifier (RNTI).
 94. The wireless device according to claim91, wherein the processing circuitry is configured to receive theindication as information in Downlink Control Information (DCI) that isused to schedule different multicast traffic channels (SC-MTCHs), theinformation indicating whether a configuration of respective multicasttraffic channels is changed.
 95. The wireless device according to claim94, wherein the information indicates one of: a new service isestablished; and an existing service is changed for the respectivemulticast traffic channels.
 96. The wireless device according to claim91, wherein the processing circuitry is configured to receive theindication as information in Downlink Control Information (DCI) that isused to schedule payload in the SC-MCCH, the information indicatingwhether a configuration of multicast traffic channels is changed. 97.The wireless device according to claim 91, wherein the processingcircuitry is configured to receive the indication as information in adirect indication message, the information indicating which multicasttraffic channel configurations are changed.
 98. The wireless deviceaccording to claim 91, wherein the indication indicates whether thechange comprises at least one of: establishment of new multicast trafficchannel configurations; and update of existing multicast traffic channelconfigurations.
 99. A non-transitory computer readable medium storing acomputer program for enabling a wireless device to obtain configurationinformation from a multicast control channel (SC-MCCH) transmitted by anetwork node, the computer program comprising instructions that, whenexecuted on at least one processor of the network node, cause the atleast one processor to: transmit an indication of a change of themulticast control channel, wherein the indication further indicateswhether the wireless device is affected by the change and needs toacquire or obtain the multicast control channel; and transmit themulticast control channel as changed according to the indication.
 100. Anon-transitory computer readable medium storing a computer program forobtaining configuration information from a multicast control channel(SC-MCCH) transmitted by a network node in a wireless network, thecomputer program comprising instructions that, when executed on at leastone processor of a wireless device, cause the at least one processor to:receive an indication of a change of the multicast control channel,wherein the indication further indicates whether the wireless device isaffected by the change and needs to acquire or obtain the multicastcontrol channel; and acquire or obtain the multicast control channelresponsive to determining that the indication indicates that thewireless device is affected by the change.